Node.js, et al: Highlights from JavaScript Chicago January Meeting

(Each month I plan to attend technical user groups in the Chicago area to (re-)learn from peers experiences with new and existing technologies and to network with like-minded techies. This blog is one in a series of recaps of some of the more interesting aspects of the meetings for my own purposes (this is a “web log” afterall) and for others to get a general taste of what’s available in the Chicago user group scene.)

User Group: JavaScript Chicago (JS.chi)
Twitter: @chicagojs
Location: CashNetUSA (200 W Jackson – In the Loop)
Meeting Date:Thursday, January 20, 2010

The js.chi meetings follow a format of two main presentations, followed by three “lightning talks” (5-min quick presentations – although I have only seen one actually achieve the 5-min timeframe).   Fairly large attendance again (20 – 30 attendees, from what I could tell), but had audio problems again, which meant it was difficult to hear beyond the first five rows or so (hint: arrive early to get a good seat – beers/sodas and networking before the meeting to help it along).

Presentations:


Prototypal Inheritance

This month, the opening presentation was an overview of prototypal inheritance in JavaScript.  Honestly, I didn’t find the topic that engaging, which combined with an apparently nervous presenter, meant that I didn’t take that many notes.  Check out the website for a video, and http://javascript.crockford.com/prototypal.html for more info.

Node.js

Jason Huggins (twitter @hugs – formerly @jhuggins) of SauceLabs (“Selenium in the cloud”) presented an overview of Node.js.  This presentation I did find intriguing, although may be more applicable to my Linux friends than those living in a Microsoft world. (If you don’t know what POSIX means, you probably won’t want to use Node.js)

Node.js, at a very high level, is a JavaScript environment that lives outside the browser.  Think: server-side JavaScript or shell-scripting on crack.  It’s a three-way marriage with the following actors:
  • Common.JS: An attempt at a common/standard JavaScript library, not tied to any specific framework.  Most other high-level languages have some core library (.Net has – well, the .Net core libs, Perl has CPAN, etc).  Includes library support for file access, database drivers, console drivers, etc. (http://commonjs.org)
  • Google’s V8 JavaScript engine: This is the JS engine in Chrome – written in C++, it’s very powerful, very fast, but really not a standalone system – intended to be run from within a browser.
  • Node.js: The glue that holds it all together. Provides a command line interpreter in addition to the JavaScript run-time environment.  Adds additional libraries to round-out common.js. (http://nodejs.org)

Node.js is fairly new to the scene – started circa Nov 2009. It requires a POSIX environment, which means additional installs in Windows-land if you want to use it. Use out-of-the-box for Linux and friends.

Per the presenter, search Google for “node.js jsconf slides” for the originators presentation slides, which go into depth about the project. (You can also find video of this slide presentation with audio overlay at http://blip.tv/file/3152542 or just this presenter’s slides at http://www.slideshare.net/hugs/nodejs-javascript-chicago-meetup)

So what’s so great about using JavaScript outside a browser?  Well, unlike most other scripting languages, JavaScript is (can be) event-driven – meaning you can provide anonymous functions to method calls to create async callbacks when handling results, providing a more responsive and scalable system, as well as being a feature-rich language:
db.query($sql, function(result) {
       //do something with result
}

The framework provides library inheritance (like the “using” keyword in C#, #include in C).
                var sys = require(“sys”);
                var http = require(“http”);
                http.createServer(…);

The presenter’s proof-of-concept demo was a ~20 line JavaScript application that bound itself to a port as an http listener and responded with an HTTP 200 request and “Hello World” body to any incoming request.  Could be very useful for mocking up web interfaces.

Some drawbacks:
-          Library is new and immature – but appears to be growing up quickly.
-          Currently no “step debugging” support – start loving log output now L

Other notes:
The presenter is a founder of SauceLabs (http://saucelab.com), which provides cloud-based support for the UI testing framework Selenium (http://seleniumhq.org/).  I’ve been wanting to play with Selenium, and if/when I do, this looks like an interesting model for grid-based/pay-as-you-go script agents.

Lightning Talks:

  • Chad Norwood presented his JavaScript-based project for using Google Maps as a filter for large, geography-based data sets.  Specifically, he’s linked Google Maps and Google Calendar to allow the user to display/filter calendar entries by physical location.  In his example, he used a usergroup calendar (such as http://chicagotechcal.com– love it!) and could zoom in/out to narrow/widen the list of events and chart them on the map. Cool idea.  Play with it here: http://chadnorwood.com/gcm
  • The second talk was kind of a teaser for another presentation at a local Ruby group. MongoDB is a JSON-based database (apparently similar to CouchDB) which stores data as BSON (Binary JSON). Its schema-less, so stores the objects as you define them. I could see this useful for cases where you may want to cache AJAX responses for improved performance, but I struggle to see where/how you would use this in an enterprise environment (full disclosure: I’m a big fan of RDBMS, so you’d have to really wow me to move away from a relational design).  More can be found here:  http://mongo.kylebanker.com

That’s all for tonight.  Typically, after the meeting a smaller group goes to the Elephant and Castle pub for drinks and networking – but after a long week, and a list of must-do’s for the client status meeting the next morning, I opted instead to head home.

Bonus Teaser:

I’m working on a blog (rather, the code which will lead to a blog) as an intro to Microsoft’s ASP.NET Charting controls and Google’s .NET Analytics API.  Think: Building your own custom Google Analytics charts.  Why? Because I want to see them on my Flash-less iPhone. And ‘cuz I’m a geek.